Previously, large-object inserts followed LT-first ordering: write data to long-term storage, then write the redirect tombstone to high-volume. Concurrent inserts or pod kills between those two steps left an orphaned long-term object — data in LT with no tombstone in HV — permanently unreachable with no recovery path.

This flips the ordering to HV-first: write the tombstone first, then write the data. A failure between the two steps now produces a headless tombstone (tombstone in HV, no data in LT) instead. Headless tombstones are safe and self-healing: reads return None, deletes remove them, and re-inserts overwrite them.

The tradeoff is deliberate: we lower the risk of orphans in long-term storage — which are silent data leaks with no recovery — and instead accept headless tombstones, which are a well-defined recoverable state.

For small objects, a new put_non_tombstone trait method atomically rejects the write if a tombstone already exists at the key, routing the payload to long-term storage instead. BigTable implements this with CheckAndMutateRowRequest; other backends fall back to a non-atomic read-then-write.

One gap remains: a concurrent insert + delete can still race to produce an orphaned long-term object. Fixing that requires per-key serialization. This PR is an intermediary improvement; the full solution with no orphans at all is tracked separately.

Ref FS-236